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Abstract 


This paper introduces and analyzes a class of nonlinear con- 
gestion control algorithms called binomial algorithms, moti- 
vated in part by the needs of streaming audio and video ap- 
plications for which a drastic reduction in transmission rate 
upon congestion is problematic. Binomial algorithms gen- 
eralize TCP-style additive-increase by increasing inversely 
proportional to a power k of the current window (for TCP, 
k, = 0) ; they generalize TCP-style multiplicative-decrease 
by decreasing proportional to a power | of the current win- 
dow (for TCP, | = 1). We show that there are an infinite 
number of deployable TCP-friendly binomial algorithms, all 
of which satisfy k + 1 = 1, and that all binomial algorithms 
converge to fairness under a synchronized-feedback assump- 
tion provided k +1 > 0;k,l > 0. Our simulation results 
show that binomial algorithms interact well with TCP across 
a RED gateway. We focus on two particular algorithms, 
ITAD (inverse-increase/additive-decrease, k = 1,1 = 0) and 
SQRT (k = | = 0.5), showing that they are well-suited to 
applications that do not react well to large TCP-style win- 
dow reductions. We also find that TCP-friendliness in terms 
of the relationship between throughput and loss rate of an al- 
gorithm does not necessarily imply fairness relative to TCP 
performance, especially for drop-tail bottleneck gateways. 


1 Introduction 


The stability of the Internet to date has in large part been due 
to the congestion control and avoidance algorithms [15] im- 
plemented in its dominant transport protocol, TCP [28, 34]. 
Based on the principle of additive-increase/multiplicative- 
decrease (AIMD) [6], a TCP connection probes for extra 
bandwidth by increasing its congestion window linearly with 
time, and on detecting congestion, reducing its window mul- 
tiplicatively by a factor of two. Under certain assumptions 
of synchronized feedback, Chiu and Jain have shown that an 
AIMD control scheme converges to a stable and fair operat- 
ing point [6], providing a sound basis for Jacobson’s algo- 
rithms found in most current TCP implementations [1]. 
TCP is not well-suited for several emerging applications 
such as streaming and real-time audio and video because the 
reliability and ordering semantics it ensures increases end- 
to-end delays and delay variations. To be safe for deploy- 


ment in the Internet, however, the protocols used by these 
applications must implement congestion control algorithms 
that are stable and interact well with TCP. Such protocols 
are called “TCP compatible” [3] or “TCP fair’. They ensure 
that the TCP connections using AIMD get their fair allo- 
cation of bandwidth in the presence of these protocols and 
vice versa. One notion that has been proposed to capture 
“TCP compatibility” is “TCP-friendliness”. It is well known 
that the throughput A of a flow with TCP’s AIMD conges- 
tion control (increase factor a = 1 packet, decrease factor 
G = 1/2)is related to its loss rate pas \ x S/(R,/p), where 
S is the packet size [19, 25, 10, 26]. An algorithm is TCP- 
friendly [20] if its throughput A « S/(R,/p) with the same 
constant of proportionality as for a TCP connection with the 
same packet size and round-trip time. 

In this paper, we present and evaluate a new class of 
nonlinear congestion control algorithms for Internet trans- 
port protocols and applications. Our work is motivated by 
two important goals. First, we seek to develop and analyze a 
family of algorithms for applications such as Internet audio 
and video that do not react well to the large “factor-of-two” 
rate reductions that a TCP-style multiplicative-decrease en- 
tails, because of the drastic degradations in user-perceived 
quality that result. Second, we seek to achieve a deeper un- 
derstanding of TCP-compatible congestion control by gen- 
eralizing the class of linear control algorithms, and under- 
standing how a TCP-friendly algorithm competes with TCP 
for bottleneck resources. 

An AIMD control algorithm may be expressed as: 


I wisR — uy,+ta;a>0 
D: Wt+6t — (1 — B)w;;0 < B < 1, (1) 


where J refers to the increase in window as a result of re- 
ceipt of one window of acknowledgements in a RTT and D 
refers to the decrease in window on detection of a loss by the 
sender, w, the window size at time t, R the round-trip time 
of the flow, and a and ( are constants. We have assumed a 
linear increase in window in the RTT. 

To better understand the notions of TCP-friendliness and 
the trade-offs between the increase and decrease rules, we 
generalize the AIMD rules in the following way: 


I witr — wrt a/wi;a > 0 
D: Wiest — W; — Bwls0<B<1 (2) 


These rules generalize the class of linear controls. For k = 
0, 1 = 1, we get AIMD; for k = —1,1 = 1, we get MIMD 
(multiplicative increase/multiplicative decrease used by slow 
start in TCP [15]); for k = —1,1 = 0, we get MIAD; and 
for k = 0,1 = 0 we get AIAD, thereby covering the class of 
all linear controls. 

We call this family of algorithms binomial congestion 
control algorithms, because their control expressions involve 
the addition of two algebraic terms with different exponents. 
They are interesting because of their simplicity, and because 
they possess the property that any / < 1 has a decrease 
that is in general Jess than a multiplicative decrease, a desir- 
able property for streaming and real-time audio and video. 
If there exist values of k and / (other than k = 0,1 = 1) 
for which binomial algorithms are TCP-friendly, then it pro- 
vides a spectrum of potentially safe congestion management 
mechanisms that are usable by Internet applications which 
do not react well to large and drastic rate reductions. It 
should be noted that varying a and ( also help in reduc- 
ing the oscillations. However, they still keep the reduction 
multiplicative and as a result, the same value of a and 3 can- 
not be used across wide range of bandwidth*delay values by 
an application that desires an absolute bound on the inherent 
oscillations due to congestion control algorithm. For that 
purpose (for example, if the layers in layered media are ad- 
ditively spaced), a and (3 have to be made functions of cur- 
rent window values which is what binomial algorithms help 
achieve. 

Our major finding is that TCP-friendly binomial conges- 
tion control schemes do exist. Based on the analysis and 
simulation, we present the following findings: 


e The )-p relationship. For the binomial family of con- 
1 
trols, \ o 1/p**47. In particular, the linear control 
protocols MIMD and AIAD have X « 1/p, which 
is significantly more aggressive than the AIMD TCP- 
compatible relationship, while MIAD is unstable. 


The & + / rule. A binomial algorithm is TCP-friendly 
if and only if&k +1 = 1 and/ < 1 for suitable a and @. 
This implies that there is a wide range of TCP-friendly 
binomial controls parametrized by & and 1, and appli- 
cations can choose from this family depending on their 
needs and the level of rate degradation they can sus- 
tain. Furthermore, we show that under a synchronous 
feedback assumption, all the binomial control proto- 
cols converge to fairness as long as k > 0,1 > 0 and 
k +1 > 0. In particular, all the TCP-friendly binomial 
algorithms converge to fair allocations. 


ITAD and SQRT control. Of this family, we evaluate 
two interesting TCP-friendly algorithms in the (k, 1) 
space: (k = 1,1 = 0) and (k = 1/2,1 = 1/2). We call 
the first TAD (inverse-increase/additive decrease) be- 
cause its increase rule is inversely proportional to the 
current window, and the second SQRT because both its 
increase is inversely proportional and decrease propor- 
tional to the square-root of the current window. Our 
simulations show that both IAD and SQRT interact 
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Figure 1. The (k,/) space of nonlinear controls from our 
family, with - k +1 = 1 line showing the set of TCP- 
compatible controls. 


well with TCP AIMD across a wide range of network 
conditions over a RED bottleneck gateway. 


TCP-friendliness vs. TCP compatibility. Over 
a wide range of parameters, we discover that 
TCP-friendliness does not necessarily imply TCP- 
compatibility. The unfairness stems from the buffer 
management algorithms implemented at a congested 
gateway and how buffers are sized at a drop-tail (FIFO) 
gateway. Fortunately, an active queue management 
scheme like Random Early Drop (RED) at the bottle- 
neck link alleviates this unfairness problem by explic- 
itly equalizing packet loss rates across flows. Hence, 
while binomial algorithms are TCP-friendly (because 
they satisfy (\,p) relationship, they become TCP- 
compatible in the presence of RED gateways. 


Figure 1 summarizes the qualitative features of a bi- 
nomial algorithms in the (k,/) space, including the points 
where it corresponds to the four linear controls, the line 
segment where it is TCP-friendly, and the regions where 
it is more and less aggressive than TCP AIMD. An in- 
teresting observation that follows from this figure and our 
analysis is that of all the TCP-friendly binomial algorithms 
(A +1 = 1,1 < 1), AIMD is most aggressive in prob- 
ing for available bandwidth. In this sense, AIMD is the 
most efficient and best suited binomial algorithm for bulk 
data transfer applications that can tolerate large reductions 
in available capacity upon encountering congestion. (Note 
that we assume that window size is always greater than 1, so 
1/W* < 1). This observation shows the suitability of bino- 
mial algorithms as a good theoretical framework for evalu- 
ating additive increase/multiplicative decrease algorithms. 

The rest of this paper is organized as follows. In Sec- 
tion 2, we discuss and analyze the properties of binomial 
algorithms. In Section 3, we delve into the IAD and SQRT 
controls, presenting several simulation results with RED 
gateways and evaluating fairness with competing TCP con- 
nections. In Section 4, we discuss the interactions between 
binomial algorithms and TCP in the presence of drop-tail 
gateways. We describe the performance results of our imple- 


mentation of SQRT algorithm for an Internet audio applica- 
tion in Section 5. We compare our work to past research on 
congestion management in Section 7 and conclude in Sec- 
tion 8. 


2 Binomial congestion control algorithms 


In this section, we present and analyze the properties of bi- 
nomial congestion control algorithms. We start by providing 
some intuition about the sample paths traversed by the con- 
gestion window in a binomial algorithm, and showing that 
it converges to fairness under simplified conditions of syn- 
chronized feedback to sources. The intuition section makes 
simplifying assumptions but later, we corroborate our results 
by deriving an analytic formula that relates the throughput 
of a binomial algorithm to the loss rate it observes. We then, 
use this formula to obtain the conditions under which a bi- 
nomial algorithm is TCP-friendly. 


2.1 Intuition 


We use the technique of Chiu and Jain and represent the two- 
source case as a “phase plot,’ where the axes correspond 
to the current window sizes, «;, of each source (for conve- 
nience, we normalize each x; to a number between 0 and 1, 
so it represents the fraction of the total window size aggre- 
gated across all competing sources). As the system evolves 
with time, the two sources adjust their windows according to 
the control equations, leading to a sample path in this phase 
space. The key to understanding binomial controls is to re- 
alize how these paths move in the phase space. To start with, 
we summarize how linear controls behave [6]: 


1. Additive-increase/decrease: Moves parallel to the 45 °- 
line. Additive-increase improves fairness (in the sense 
of Jain’s fairness index!), additive-decrease reduces it. 


2. Multiplicative-increase/decrease: Moves along the line 
connecting (#1,2%2) to the origin. Fairness is un- 
changed. 


Because binomial algorithms are non linear, their evolu- 
tion in the phase plot is not always along straight line seg- 
ments. Figure 2 shows a portion of one such sample path 
highlighting the increase and decrease parts. For all val- 
ues of k > 0, the increase in x; and x2 are not equal—the 
smaller of the two values increases more than the larger one. 
It is clear that this leads to a fairer allocation than if both 
sources did additive-increase by the same constant amount. 
On the other hand, values of / < 1 in the decrease phase 
worsen fairness. However, binomial algorithms still conver- 
gence to fairness as we show in Section 2.2. 

The parameters & and / represent the aggressiveness of 
probing and conservativeness of congestion response of a bi- 
nomial control algorithm. A small value for & implies that 
the algorithm is more aggressive in probing for additional 


‘For a network with n connections each with a share x; of a 
resource, the fairness index f = ()*ai)’/(n )> 27) [16]. 


bandwidth, while a large value of / implies that the algorithm 
displays large window reductions on encountering conges- 
tion. Thus, it would seem that there is a trade-off between k 
and / in order for for a binomial protocol to achieve a certain 
throughput at some loss rate. 

Indeed, in Section 2.3, we show that at any loss rate, the 
throughput depends on the sum of the two exponents, k + 1. 
As a corollary, we find that a binomial algorithm is TCP- 
friendly if and only if k +17 = 1 andl < 1. We call this the 
k +l rule, which represents a fundamental tradeoff between 
probing aggressiveness and the responsiveness of window 
reduction. Figure 1 shows the features of the (k,1) space. 
We consider schemes for which / > 1 as unstable (Figure 1), 
since there always exists a window size w; (assuming wy > 
1) above which w; < Bw for any constant @. It can be 
made stable by having it not cut down window by an amount 
more than the current window but that involves modifying 
the basic increase decrease rules and thus, we consider them 
unstable. Similarly, schemes for which k + | < —1 are also 
unstable because as k +/ rule will show, A does not decrease 
with increasing p in this realm. As a result, the window for a 
connection will keep on increasing (or remain same) as loss 
rate is increased. 


2.2 Convergence to fairness 


In this section, we show that a network with two sources 
implementing the same binomial control algorithm with 
k,l > 0 converge to a fair and efficient operating point 
(1 = x2 = 1/2), provided that k +1 > 0. The argument 
is easily extended to a network of n > 2 sources by consid- 
ering them pairwise. We assume that the network provides 
synchronized feedback about congestion to all the sources”. 
We do not claim that this models the reality of Internet con- 
gestion well, but this analysis provides good insight into the 
results that follow. 

Without loss of generality, suppose x1 < x2, which cor- 
responds to points above the x2 = 2, equi-fairness line 
in Figure 2 (an analogous argument can be made when 
%2 < 21). First, consider the left-most picture that shows 
how a window increase evolves. When k = 0, the increase 
is additive, parallel to the 45°-line (along line AB). When 
k > 0, the increase curve lies below the k = 0 line since 
the amount of increase in 2, is larger than the corresponding 
increase in x2 (note x; < x2). Therefore, it intersects the 
maximum-utilization line 7; + x2 = 1 at a point C, to the 
right of where the k = 0 line intersects it. Such an increase 
improves efficiency, since x; + x2 increases, and moves to- 
wards a fairer allocation (i.e., towards the intersection of the 
equi-fairness and maximum-utilization lines). 

Now, consider a window reduction. Observe that when 
1 = 0 (additive decrease), the window reduction occurs 
along the 45° line (along line DE), worsening fairness. 
When | = 1, the decrease is multiplicative and moves 
along the line to the origin without altering fairness. For 
0 <1 < 1, the window reduction occurs along a curve with 


? This is the same network model as in Chiu and Jain’s work [6]. 
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Figure 2. Sample path showing the convergence to fairness for an inverse increase proportional decrease algorithm. 


shape as shown in the middle picture of Figure 2; this curve 
is in-between the previous two lines (J = 0 and / = 1 lines) 
and causes the system to evolve to an under-utilized region 
of the curve where 4; + % < 1. This curve lies strictly 
below the / = 0 line because the tangent at each point has a 
slope = zh, [x > 1 when z2 > x1. Therefore, it intersects 
the maximum-utilization line at a point F which is closer to 
the fair allocation point relative to the previous intersection 
of the sample path with that line. 

The key to the convergence argument is to observe that 
the successive points of intersection of a binomial curve with 
the maximum-utilization line x; + x2 = 1 always progress 
toward the fair allocation point. When x2 > 21, this con- 
tinually moves downwards, when x2 < 21, it continually 
moves upwards towards the 72 = x; point. Once x1 = 22, 
a binomial algorithm behaves exactly like a linear algorithm, 
moving on the x; = 2X2 equi-fairness line. 

It is easy to see that all we require in the above argu- 
ment is for at least one of & and / to be larger than zero, 
since the sample path needs to move to the right at some 
stage. When k = | = 0, the algorithm is the linear 
additive-increase/additive-decrease scheme, which does not 
converge. The window evolution here remains on the 45 °- 
line passing through any point (21, 72), without moving to- 
ward the fair allocation point. 

This proof is valid under the synchronized feedback as- 
sumption and shows that a network in which all sources im- 
plement the same binomial control algorithm converges to 
a fair operating point. We note that it does not address the 
case of different binomial algorithms coexisting in the same 
network. 


2.3 Throughput 


We now analyze the throughput of a binomial algorithm 
as a function of the loss rate it experiences. We start with 
the steady-state model studied for TCP by Lakshman and 
Madhow [18] and Floyd [10]. Using the increase rule of 
Equation 2, we get using a continuous fluid approximation 
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Figure 3. Functional form of window vs time curve. 


and linear interpolation of the window between w; and 
Wt+R: 


dw a were 2 
dt  w*.R k+l sR 
G3) 


where C’ is an integration constant. 

The functional form of this curve is shown in Figure 3. 
We are interested in two parameters marked in the figure: 
Tp, the time between two successive packet drops, and N p, 
the number of packets between two successive drops. Both 
these are independent of “time-shifting” the curve along the 
horizontal (time) axis, which implies that one can arrange 
it such that a downward extrapolation of the curve passes 
through the origin. That is, without loss of generality and 
with no change to T’p and Np, one can set C' = 0. 

Let W,,, be the maximum value of the window w; at time 
ty (Figure 3), at which a packet drop occurs signifying con- 
gestion to the sender. Then, one can write expressions for 


Tp and Np as follows: 
Tp = to-t 


Substituting w;, = Wm andw,, = Wm —- BW in Equation 
3, we get 
Tp = — (WEY — (Wn — AWE) 
a(k+1)" ™ as ms 
RW? I-1)k 
= —"*.{1-(1- pw, ae 


= 2 B(Win + O(Wmn*)) 


a 
k+l 
x eat (when <landB<<W- (4) 


The leading term in T’p therefore varies as WE, with 
the succeeding terms becoming increasingly insignificant. 
Np is the shaded area under the curve in Figure 3. 


te t a 
No = +n f IF] /Rdt (5) 
ti R 
Calculating the integral, we get: 
1 war ae 
Np = Qahalm ‘ 7 @ ~ ewe Bye 
1 
ee Balm BO + k)W!~" (leading term) 
= Poyeetes (6) 


The average throughput (in packets per second), of a flow 
using binomial congestion control is the number of packets 
sent in each epoch between successive drops (N p) divided 
by the duration between drops (Tp). The packet loss prob- 
ability, p = 1/Np. Writing A and p in terms of W,, by 
substituting the expressions for Np and Tp yields: 


1 


— (S)1/(kHI4 
A= GO FATA 


(7) 


Thus, A « SITY for a protocol in this family. This 


implies that for such a protocol to be TCP-friendly, 4 must 


vary as ar , which implies that: 


k+l=1 (8) 


To first order, choosing a/ to be the same as for TCP 
would achieve similar performance. Note that in our analy- 
sis above we have assumed a linear interpolation of window 
between w; and wy4, 1.e We assume an increase in window 
by one in a RTT for TCP rather than an increase by 1/w on 
receipt of each acknowledgement. 

These results also hold for the random-loss model first 
analyzed by Ott et al. in the context of TCP [25]. Un- 
like in the steady-state model where losses happen period- 
ically when the sender’s window reaches W,,,, losses in the 


random-loss model are modeled as Bernoulli trials where 
each packet is independently lost with probability p. 

We use the stochastic approximation technique for TCP 
performance described by Wang and Schwartz [36]. We 
treat the window value after receiving an acknowledgment 
with sequence number ¢, w;, as a stochastic process and cal- 
culate its average value in the steady state. If we run the 
algorithm for a long time, the resulting congestion proba- 
bility (the number of window reductions over the number 
of packets sent) is p. Then, in the steady state, the random 
process w, evolves as follows: given w;, with probability 
(1 — p), the packet is not lost and the sender’s window in- 
creases, SO Wi41 = We + a/ wert, whereas with probability 
p, the packet is lost, forcing the window to reduce giving 
Wtet1 = Wt — Bw. 

Using this, we can calculate the average “drift” D in the 
window when w; = w. D(w) = (1 — p)a/w*t! — pBu!. 
Assuming that the stochastic process w; has a stationary 
distribution, w, must have most of its probability around the 
region for w = Wsteady such that D(Weteady) = 0. Thus: 


(1 —p)a l 
Wee pp steady ( ) 
a i 
> W steady x Ga ifp<<l (10) 


We emphasize that p is the per-packet loss probability. As 
shown in the steady-state analysis above, W steady iS a good 
approximation to the time average of the random process w ;¢. 
The result, that \ = (Beery Fpl ery ee Te 
therefore follows for the random-loss model as well. 

This relationship establishes the fact that for a given loss 
rate and identical conditions, TCP AIMD and a binomial al- 
gorithm satisfying k + / rule can achieve the same through- 
put. Further, it shows that for a given loss rate, two bi- 
nomial connections will achieve same throughput provided 
other conditions are same. 


3 Simulation results 


In this section, we present the results of our ns-2 [24] simu- 
lations of binomial control algorithms. We start by investi- 
gating the interactions between connections running a TCP- 
friendly binomial control algorithm (i.e., one that satisfies 
the k + 1 rule) and TCP, as a function of k, which deter- 
mines how aggressive the window increase factor is. We 
then investigate the performance of two specific members of 
this family: I[AD (inverse-increase/additive-decrease; k = 
1,/ = 0) and SQRT (k = | = 0.5; this corresponds to an 
increase proportional to the square-root of the current win- 
dow and a decrease proportional to it). We conclude this 
section by studying the performance of ITAD and SQRT in 
the presence of multiple bottlenecks. 

Our single bottleneck simulations used the topology 
shown in Figure 4. It consists of n connections sharing a 
bottleneck link with total bandwidth equal to 6; all connec- 
tions have an identical round-trip propagation delay equal 


source-| sink-1 


source-2 J sink-2 
100Mb 100Mb/ © 
// 
100Mb // 
\ OoMb 
source-k \ YA, sink-k 
“" 1OOMb BW=b 100Mb." 
Router-1 ans Router-2 ane 
a ‘ 
100Mb OMb 
aie OOM @ 
/ 
source-n / sink-n 


eo 


Figure 4. Simulation topology (delays of links for which no 
delay is specified are all equal such that the round-trip time 
for each connection = RT'T ms). 


to RTT (we change b and RTT in various simulations). 
We implemented the transport protocol by modifying the 
congestion avoidance algorithm used by TCP; we replaced 
AIMD with the binomial family. However, we did not mod- 
ify the connection start-up or timeout routines; they continue 
to use slow-start and timeouts as before. Thus, the effect of 
slow start and timeouts on connection throughput is same as 
for a normal TCP connection. Each source always has data 
to send, modeled using ns’s “FTP” application. In all our 
experiments, we simulated each topology and workload ten 
times and calculated both the average and sample standard 
deviation of the observed values. The figures and graphs 
display this information. 

In this section, we present performance results using 
Floyd and Jacobson’s Random Early Drop (RED) buffer 
management algorithm at the bottleneck gateway [12]. The 
maximum queue size @ at the bottleneck was set to bx RTT, 
the bandwidth-delay product of the path. The minimum and 
maximum drop thresholds (min¢p, and maz+p,) were set to 
0.2 x Q and 0.8 x Q respectively, and the connections used 
a packet size of 1K Byte. Each connection was started at uni- 
formly chosen random times in [0, 2] seconds and through- 
put was calculated from t = 10s tot = 20s to give sufficient 
time for the connections to stabilize and to filter out startup 
transients. Later in the section, we also present results show- 
ing startup effects and impulse response of a binomial algo- 
rithm on TCP and vice versa. 


3.1 TCP-compatibility 


Our first set of results (Figure 5) show how binomial al- 
gorithms interact with each other and with TCP. To study 
the effect of k and 1 on TCP, we simulated two connec- 
tions (n = 2), one TCP and the other a binomial algorithm 
parametrized by &. We show three sets of results correspond- 
ing to the three cases & + | equal to, less than, and greater 
than 1. For these simple scenarios, these results validate the 
k+l rule for TCP-friendliness, since the long-term through- 
put for the binomial algorithms for which k +] = 1 are close 
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Figure 5. Ratio of the throughput of TCP AIMD to the 
throughput of a binomial algorithm, as a function of &. The 
algorithms that satisfy the & + / rule are the ones for which 
this ratio is closest to unity. When k + 1 = 0.5, the binomial 
algorithm obtains much higher throughput relative to TCP 
and when k + 1 = 1.5, TCP obtains much higher through- 
put relative to binomial algorithm, as predicted by the anal- 
ysis. The error bars show the 95% confidence interval of 
the throughput ratio. In these experiments, b = 3 Mbps and 
RTT = 50 ms. 


to that of TCP. These results also show that TCP-friendliness 
implies TCP-compatibility across RED gateways. 


3.2. ILAD Algorithm 


We now turn to IIAD, which is relatively less aggressive in 
the rate at which it probes for bandwidth (& = 1), but at the 
same time only reduces its window by a constant upon con- 
gestion (1 = 0). We choose the values of a and (3 such that 
the theoretical throughput of IIAD is close to the through- 
put of TCP AIMD. There are an infinite number of val- 
ues for a@ and ( corresponding to this; we pick one pair, 
a=1,0=0.6. 

We compare the fairness of IIAD relative to another 
IIAD instance and to a TCP/Reno sharing the same bottle- 
neck using the topology and workload in Figure 4. In these 
experiments, nm = 2 and each connection was started at a 
random time in [0,2] seconds. Each individual experiment 
was conducted using a bottleneck bandwidth 6 of 1.5 Mbps 
and the round-trip time RTT was varied between 50 ms and 
200 ms. 

Figure 6 plots the throughput ratio for two ITAD connec- 
tions on one curve and for one ITAD and one TCP connec- 
tion on the other curve. These results show that ITAD is fair 
to both the ITAD and to TCP across a range of RTT val- 
ues. However, the standard deviation of the results increases 
as RTT increases. This is because as RT'T increases, each 
connection takes a greater amount of time to reach the op- 
timum available bandwidth. Furthermore, when persistent 
losses occur leading to a timeout (recall that these experi- 
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Figure 6. Ratio of throughputs of two connections sharing 
the bottleneck along with 95% confidence intervals (n = 
2,b = 1.5 Mbps). 


ments use a modified TCP source and sink), the congestion 
window shrinks to one packet and slow start occurs. The ini- 
tial start-up effects and response to timeouts take longer to 
stabilize at higher delays, resulting in the correspondingly 
higher variance. The start-up effects are exacerbated for 
IIAD because it is less aggressive than AIMD, and responds 
relatively slower to any spare bandwidth. This is the reason 
that at higher delays, IAD sometimes loses to TCP; the con- 
nections experience losses during slow start and ITAD takes 
longer to ramp to its share of bandwidth. Figure 6 shows that 
IIAD and TCP AIMD are fair to each other over long time 
scales. We observed the same results and behavior across a 
range of bottleneck bandwidths. 
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Figure 7. Congestion window evolution at the sender for 
two IIAD connections that start at random times in [0, 2] sec- 
onds. In this experiment, 6 = 1.5 Mbps and RT'T' = 50 ms. 


For one of these experiments, we look at the evolution 
of the congestion window. Figure 7 shows this for the two 
IIAD connections, showing the expected increase and de- 
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Figure 8. Congestion window variation for the IAD and 
TCP Reno connections started at random times. 


crease behavior as a function of time. For want of space, 
we do not show the sequence trace for these two connec- 
tions here, but the two connections quickly achieve the same 
slopes signifying that they share bandwidth well with each 
other. We observed such good sharing across a range of b 
and RTT values. 

More interesting is the interaction between IIAD and 
TCP in terms of the evolution of their congestion windows 
(Figure 8). We observe that the window values quickly be- 
come similar, and even though the TCP connection started 
later, it was able to obtain its share of bandwidth without 
any difficulty. 
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Figure 9. Slow start response of an ITAD flow to another 
long-running ITAD flow. In this experiment, b = 1.5 Mbps, 
RTT =50 ms. 


We now consider the impulse-response behavior of the 
binomial control algorithms. Our experiences with these 
experiments across several binomial algorithms have con- 
vinced us that slow start (or a similar mechanism) is an im- 
portant component of any practical protocol to ensure that a 


connection converges relatively quickly, within a few RT'T's 
to the fair value. We show an example of this in Figure 9, 
which shows how slow start enables a new ITAD connection 
to catch up and share bandwidth with another long-running 
IIAD connection. 


TCP conn. 
ILD conn. ------- 


Window(packets) 


Winciees) 30 35 40 45 50 
Figure 10. Response of a long-lived ITAD flow to a TCP 


impulse. In this experiment, b = 1.5 Mbps and RT'T’ = 50 
ms. 
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Figure 11. Response of a long-lived TCP flow to an IAD 
impulse. In this experiment, b = 1.5 Mbps and RT'T’ = 50 
ms. 


We observe the same behavior when a new TCP AIMD 
connection impulse encounters a long-running ITAD, as 
shown in Figure 10. The results of the converse experiment 
are shown in Figure 11, where an ITAD impulse meets a 
long-lived TCP AIMD. These figures show that ITAD and 
TCP converge to their fair bandwidth share, with the im- 
pulses using slow start. 

These results hold when the number of connections is 
increased as well. Figure 12 shows the window variation for 
five of fifteen concurrent ITAD flows sharing the bottleneck 
link. At time t = 20 seconds, aTCP AIMD connection starts 
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Figure 12. A TCP AIMD connection grabs its fair share in 
the presence of many long-lived IIAD flows (n = 16,b = 9 
Mbps, RT'T' = 50 ms). For clarity, we only show the win- 
dow sizes of five TAD connections and the TCP connection. 


(the impulse at f = 20), and is able to grab its share of band- 
width even in the presence of several other long-lived IAD 
connections as can be seen from the TCP window evolution 
after about t = 25 seconds. Conversely, Figure 13 shows the 
window evolution of an ITAD flow that starts at time ¢ = 20 
seconds in the presence of five concurrent long-lived TCP 
connections (for clarity, we only plot the windows of two of 
the TCPs). 


3.3. SQRT algorithm results 


We now investigate the performance of the SQRT algorithm, 
which has k = 1 = 0.5. 

Although we use a = 1 and 3 = 0.6 in the reported ex- 
periments; we found that performance is relatively insensi- 
tive to small changes in 3. We do not report the results of all 
the experiments we conducted with SQRT; in particular, we 
found that the long-term fairness of SQRT connections with 
each other and with TCP are high. We obtained results very 
similar to Figure 6 (the ITAD experiments), across a wide 
range of RTT and b values, showing that when the number 
of connections is small, SQRT connections share bandwidth 
fairly with each other and with TCP AIMD. 

SQRT differs from ITAD in its aggressiveness in increas- 
ing its window and in reducing its window upon congestion. 
As a result, the details of its interaction with TCP AIMD are 
different from those of IIAD. This is shown in Figure 14, 
where a TCP impulse encounters a long-running SQRT con- 
nection at the bottleneck. We see that the two connections 
converge to their share of the bandwidth in fewer number of 
round-trip times than in the TCP-ITAD case (Figure 10). 

Figure 15 plots the time evolution of the congestion win- 
dow for concurrent SQRT and AIMD connections. As ex- 
pected, the window variations for SQRT are larger than for 
IIAD (Figure 8), but its variations are markedly smaller than 
TCP. As with ITAD, this does not affect bandwidth sharing 
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Figure 13. An IIAD flow grabs its fair allocation in the 
presence of many long-lived TCP flows (n = 6,b = 9 
Mbps, RTT = 50 ms). For clarity, we only show the win- 
dow sizes of two TCP connections and the ITAD connection. 
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impulse. In this experiment, b = 3 Mbps and RTT = 50 
ms. 


as can be seen from the window plot. We observed similar 
results for arange of RTT and b values, and when we scaled 
n to higher values. 

Finally, we consider the sensitivity of our results to the 
value of @ in the binomial algorithms by showing our re- 
sults for SQRT case (we obtained similar results for ITAD as 
well). Figure 16 plots the effect of 3 on fairness to a TCP 
connection sharing the bottleneck. We observe little varia- 
tion in the throughput ratio, but notice that fairness to TCP 
reduces at the extremes. When @ is close to 0, TCP AIMD 
loses and when /3 is close to 1, SQRT loses. This is expected 
behavior based on the magnitude of SQRT window reduc- 
tion upon congestion. 
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Figure 15. Graph showing window variation for SQRT 
and TCP AIMD connections sharing the bottleneck (b = 3 
Mbps, RTT = 50 ms). 


3.4 Multiple connections and multiple bottle- 
necks 


This section investigates the impact of scale on binomial al- 
gorithms along two dimensions: (i) increasing the number 
of concurrent connections across a single bottleneck, and (ii) 
investigating performance across multiple bottleneck links. 

To understand how several connections using different 
TCP-friendly binomial algorithms interact with each other, 
our first series of experiments looks at several concurrent 
connections running different algorithms sharing the bottle- 
neck. The topology we use is same as in Figure 4 with 
b = 50 Mbps and RTT = 50 ms. We choose values of 
k = {0, 0.25, 0.5, 0.75, 1} and / = 1 — k, and vary the total 
number of connections n. For each value of k, we set up n./5 
connections, and start each connection at a random time in 
the interval [0,2] seconds. In Figure 17, we plot the mean 
value of Jain’s fairness index (ten runs for each data point) 
along with 95% confidence intervals. 

To study the impact of multiple bottlenecks and back- 
ground traffic on the performance and fairness of binomial 
algorithms, we simulated the topology shown in Figure 18. 
The maximum number of HTTP connections for each HTTP 
source was set to five and all other parameters were set to 
the default values from ns-2 for the HTTP and CBR sources 
and sinks. The window variation for the TCP AIMD and 
IIAD sources are shown in figure 19. As can be seen from 
this figure, the bottleneck bandwidth gets distributed fairly 
among these sources even in the presence of multiple bottle- 
necks. We observed the same behavior for other sources in 
this simulation and also when we replaced the IIAD source 
a SQRT source. 


4 TCP friendliness vs TCP Compatibility 


In this section, we study the interactions between binomial 
algorithms and TCP AIMD over a drop-tail bottleneck gate- 
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Figure 16. Plot showing fairness of SQRT to TCP/Reno 
(throughput ratio) along with the 95% confidence-interval 
for various values of 3 of the SQRT algorithm (6 = 3Mbps, 
RTT = 50 ms). 


way, observing some surprising effects. Figure 20 shows the 
window variation and bottleneck buffer occupancy for two 
connections, one TCP AIMD and the other ITAD, sharing a 
drop-tail bottleneck gateway. We see that TCP starts losing 
out and its window keeps on decreasing until it starts to os- 
cillate below its fair share because no buffers are available to 
it. On the other hand, HAD starts grabbing more and more 
bandwidth. We observed similar behavior with other bino- 
mial algorithms as well. 

At first, we found this result puzzling because the theory 
and the k + / rule had predicted that as long as k +] = 1, 
the long-term throughput of a binomial algorithm would be 
equal to TCP AIMD. However, closer examination of the 
bottleneck buffer occupancy revealed the problem. In a con- 
gested network, the “steady state” of the bottleneck queue 
is close to full. IIAD is less aggressive than AIMD, and 
when it reduces its window, does not completely flush the 
queue. When a drop-tail gateway has been configured with 
a queue size of b x RTT, it ensures that TCP-style “factor- 
of-two” multiplicative decrease brings the reducing connec- 
tion’s contribution to the bottleneck occupancy down to (or 
close to) 0. This allows other competing connections to ramp 
up and also ensures that sufficient buffers are available for 
the window to increase before another “factor-of-two” re- 
duction happens. In contrast, a non-AIMD TCP-friendly bi- 
nomial algorithm, by its very design, ensures that window 
reductions are not drastic. As a result, it ends up with more 
than its fair share of the bottleneck; and a window reduc- 
tion does not flush all of its packets from the queue. In fact, 
the competing AIMD window oscillates as if it sees buffers 
equal to the additive decrease term (the amount of buffer 
freed by HAD on a reduction) of the IAD algorithm. The 
result is that drop rates observed by the two flows competing 
at a drop-tail bottleneck are not equal. This argument also 
shows how buffer provisioning is intimately tied to the win- 
dow adjustment algorithm of the end-systems for drop-tail 
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Figure 17. Plot showing Jain’s Fairness Index as a func- 
tion of the number of TCP-compatible connections sharing a 
bottleneck. In each experiment, the total number of connec- 
tions was divided equally into five categories corresponding 
to k = 0,0.25,0.5,0.75,1. In these experiments, b = 50 
Mbps, RTT = 50 ms. The (tiny) error-bars show 95% con- 
fidence intervals. 
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Figure 18. Topology with multiple bottlenecks and back- 
ground traffic. 


gateways. 

In contrast, RED gateways are designed to accommodate 
bursts and maintain small average queue sizes by providing 
early congestion indications. They seem ideally suited to 
binomial algorithms because they do not tie buffer sizing 
closely to the precise details of window adjustment of the 
end-points. Instead they vary the drop rate as a function of 
queue size making all flows see the same drop rate. This is 
yet another among the many other compelling reasons for 
the Internet infrastructure to move to a more active queue 
management scheme like RED. 

We do not view the TCP-unfairness of the binomial algo- 
rithms across drop-tail gateways as a deployment problem: 
first, the binomial algorithms obtain better throughput than 
TCP AIMD with drop-tail gateways, which augurs well for 
applications using them (and also provide an incentive for 
Internet Service Providers to move to better queue manage- 
ment schemes)! Second, any scalable scheme for detecting 
flows using more than their share of bandwidth would likely 
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Figure 19. Window variation vs. time for the topology with 
multiple bottlenecks. 
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Figure 20. Plot showing window/queue size variation for 
TCP/Reno and SQRT algorithms sharing the bottleneck with 
drop-tail gateways(b = 3 Mbps, RTT = 50 ms). 


use an active queue management scheme and not a drop-tail 
gateway, which would ensure that true fairness to TCP is 
achieved. We emphasize that the adverse interactions of the 
binomial algorithms with TCP are primarily a consequence 
of the ill effects of drop-tail queue management. 

An important consequence of the above findings and ar- 
guments is that TCP-friendliness does not necessarily imply 
TCP-compatibility since the theory assumes that drop rates 
for competing flows are equal at a gateway. We therefore 
conclude that justifying a congestion control algorithm as 
safe for deployment on the Internet purely on the basis of the 
TCP-friendly equation is dangerous. While our experience 
indicates that this is reasonable with certain types of queue 
management (such as RED), it is incorrect when congestion 
occurs at a drop-tail gateway. We believe that deriving a set 
of sufficient conditions for TCP-fair congestion control in 
drop-tail networks requires further research. 
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Figure 21. Window variation for a vat session using SQRT 
congestion control with a bottleneck configured using Dum- 
mynet (b = 50 Kbps,RT'T = 900 ms). 
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Figure 22. Window variation for a vat session using SQRT 
congestion control across an Internet path. 


5 Implementation 


We have implemented the SQRT congestion control algo- 
rithm in the Linux Kernel (version 2.2.9) to provide con- 
gestion controlled UDP sockets. We experimented with the 
Internet audio conferencing tool, vat in unicast mode. Fig- 
ure 21 shows the congestion window variation for a transfer 
as a function of 10ms time intervals for an audio session be- 
tween two Linux machines. These machines were on the 
same LAN but had a pipe of bandwidth 50Kbit/s and RTT 
900ms between them, configured using Dummynet [8]. The 
figure shows the effectiveness of SQRT congestion control 
in alleviating the large TCP-style “factor-of-two” reductions. 
The magnitude of oscillations are smaller than what AIMD 
would observe. 

Figure 22 shows the congestion window variation for a 
vat transfer between two Linux machines, one at MIT and 
the other at University of California, Berkeley. Again, the 


magnitude of oscillations are much smaller than with AIMD. 
The window keeps increasing because the bandwidth avail- 
able between these two machines was much higher than the 
64Kbps, rate at which vat samples audio data. This graph 
also demonstrates the working of SQRT across the Internet, 
since the occasional reductions are not drastic. 

We note that our algorithms can be incorporated in the 
Congestion Manager (CM) architecture to provide applica- 
tions tunable congestion control [2]. The CM exports an API 
that allows applications to learn about and adapt to the net- 
work conditions; this API can easily be extended to allow 
an application to pick the parameter (k) of a binomial algo- 
rithm, with the CM using the k + / rule to ensure that the 
choice is TCP-friendly. An audio or video application can 
then, easily use one of the TCP-friendly binomial algorithms 
over a UDP-based transport protocol. While it is unlikely 
that elastic applications that run well over TCP today will 
use a non-AIMD binomial algorithm, an implementor can 
change the TCP sender with little implementation effort. 

In fact, a protocol may switch between different TCP- 
friendly binomial algorithms in real-time, adapting to chang- 
ing network conditions. In particular, it can probe more ag- 
gressively if it observes no congestion for a while, and probe 
less aggressively otherwise. 


6 Deployment of Binomial Controls in the In- 
ternet 


An issue of concern for wide scale deployment of IIAD algo- 
rithms in the Internet may be that their relatively mild reduc- 
tion in window on experiencing congestion may affect Inter- 
net stability. However, we believe that the primary threat to 
the Internet stability comes not from the flows using some 
form of TCP-compatible congestion control but from flows 
that do not use any congestion control at all. Moreover, pre- 
vention of congestion collapse does not require that flows 
reduce their sending rate by half in response to a single con- 
gestion indication. The binomial algorithms, being window 
based and TCP-friendly, cannot cause congestion collapse 
simply by the fact that they send out data only in response 
to receipt of successful acknowledgements (except during 
timeouts) at the receiver. Moreover, in response to even a 
single loss, these algorithms reduce their window and hence 
alleviate congestion by stopping data transmission till the 
network acknowledges (or delivers) sufficient data (equal to 
cutdown) after that loss. 

Another issue may be that a and ( values of TCP’s 
AIMD can be adjusted to provide a more stable congestion 
control as against using binomial controls. As mentioned 
earlier, adjusting a and ( can only provide relative and not 
absolute (or fixed) bounds on oscillations due to congestion 
control. Moreover, binomial controls provide a framework 
for studying window based congestion control for multime- 
dia applications of which TCP AIMD is one possibility. 
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7 Related work 


There has been significant work over the past fifteen years 
in the area of network congestion management, especially 
on end-system mechanisms. 

Chiu and Jain analyze the performance of linear controls, 
deriving the conditions for efficient convergence to fairness 
under a synchronized-feedback assumption [6]. They allude 
to non-linear controls and briefly discuss some of their prop- 
erties, concluding that they seem more complex and inferior 
to linear controls. To our knowledge, a thorough analysis 
and evaluation of any family of nonlinear congestion control 
algorithms has not been done until now. We also focus on 
TCP-compatibility, recognizing the large deployed base of 
TCP AIMD algorithms. 

Much of the classical literature on end-system conges- 
tion management was motivated primarily by reliable uni- 
cast transport, and included both window- and rate-based 
approaches. In addition to Jacobson’s TCP algorithms [15], 
prominent examples and studies include Ramakrishnan and 
Jain’s DECBit scheme that was linear with a multiplicative- 
decrease factor (3) of 7/8, rate-based control in the Ver- 
satile Message Transport Protocol (VMTP) [5], Clark et 
al.’s NETBLT [7], Keshav’s packet-pair approach (which re- 
quires flow isolation at congested routers) [17], and Faber et 
al.’s Dynamic Time Windows [9]. 

Subsequent to the development and deployment of 
TCP’s algorithms in the Internet, Wang and Crowcroft pro- 
posed “Tri-S” (slow start and search) [37] to improve TCP’s 
slow start. Brakmo and Peterson proposed TCP Vegas [4], 
which attempted to improve TCP’s congestion avoidance 
and loss recovery. More recently, a number of enhance- 
ments have been proposed to TCP congestion control, in- 
cluding the persistent fast recovery of Newreno [14], selec- 
tive acknowledgments (SACK) [22], and forward acknow]- 
edgments (FACK) [21]. RFC 2581 describes the recom- 
mended algorithms for proper congestion control in TCP [1]. 
[13] has formulated congestion control as a global optimiza- 
tion problem and has proposed a class of congestion control 
policies based on rewards and costs. 

While these TCP enhancements are interesting, signif- 
icant recent trends in Internet applications and traffic have 
led to a renewed interest in in end-system congestion con- 
trol protocols. Several emerging applications including uni- 
cast audio and video are best transported over an application- 
level protocol running over UDP, rather than over TCP be- 
cause they do not require a fully-reliable in-order deliv- 
ery abstraction. Using TCP leads to a large delay varia- 
tion caused by retransmissions, and perceptual quality shows 
sudden degradations in the face of a TCP-style window re- 
duction for these applications. 

Much recent work has focused on congestion control for 
adaptive applications. Rejaie et al.’s Rate Adaptation Pro- 
tocol (RAP) uses AIMD, relying on frequent receiver ac- 
knowledgments to adjust the sender’s rate [31]. They also 
propose a quality adaptation algorithm for discretely-layered 
streams at the receiver to handle the rate variations trig- 
gered by AIMD [30]. In the context of multicast, McCanne 


et al.’s receiver-driven layered multicast (RLM) incorpo- 
rates a probing and rate reduction mechanism for layered 
video [23]. Sisalem and Schulzrinne’s Loss-Delay-based 
Adjustment (LDA) scheme uses an AIMD rate control at the 
sender, using RTCP [32] for feedback [33]. Schemes like 
RAP and LDA can use a binomial algorithm (e.g., HAD or 
SQRT) to avoid drastic rate reductions on encountering con- 
gestion. 

To combat the ill-effects of multiplicative decrease on 
a single packet loss, various researchers have been look- 
ing at the class of “equation-based control algorithms” [20, 
27, 35]. These are schemes where the sender measures the 
packet loss rate and round-trip time over some past time and 
uses these estimates to determine a TCP-compatible trans- 
mission rate based on an equation relating TCP throughput 
to the loss rate [26]. The effectiveness of such schemes 
depends critically on the method used to estimate loss 
rate [29, 11]. It will be interesting to compare binomial al- 
gorithms with equation-based control. 


8 Concluding remarks 


In this paper we presented and evaluated a new family of 
nonlinear congestion management algorithms, called bino- 
mial algorithms. They generalize the familiar class of linear 
algorithms; during the increase phase, wii, = w; + a/ wk 
and on experiencing a loss , wi4.5¢ = we — Bul. We showed 
that a network with sources running the same binomial algo- 
rithm converges to fairness under a synchronized-feedback 
assumption if k +1 > 0 and at least one of & or J is 
positive, and that the throughput of a binomial algorithm 


Ax 1/prr, where p is the loss rate it encounters. As 
a corollary, a binomial algorithm is TCP-friendly if and only 
ifk+1=1landl <1 (the k+/rule). 

The &+/ rule represents a fundamental trade-off between 
probing aggressiveness and congestion responsiveness, with 
small values of / being less drastic in window reduction. 
Hence, we believe that binomial algorithms with / < 1 are 
well-suited to applications like audio and video that do not 
react well to drastic multiplicative decrease. Our preliminary 
experiments seem to justify this hypothesis, although more 
validation and research is needed before widespread deploy- 
ment can be recommended. For applications that simply 
want to transmit as much data as quickly as they can without 
worrying about the degree of rate variations while doing so, 
the & + / rule shows that AIMD is a very good strategy. Of 
all the TCP-friendly binomial algorithms, AIMD is the most 
efficient in aggressively probing for bandwidth. 

Our simulation results showed good performance and 
interactions between binomial algorithms and TCP, espe- 
cially using RED. We also found that TCP-friendliness 
does not necessarily imply TCP-compatibility in a network 
with drop-tail gateways—a binomial algorithm like ITAD or 
SQRT obtains higher long-term throughput than TCP be- 
cause of a higher average buffer occupancy. Active queue 
management schemes like RED allow binomial algorithms 
and TCP to interact well with each other, which may be 
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viewed as another among many important reasons to elimi- 
nate drop-tail gateways from the Internet infrastructure. 

We believe that the results presented in this paper lead to 
a deeper understanding of the issues involved in the increase 
and decrease phases of a congestion management algorithm 
and in the notions of TCP-friendliness and TCP-fairness. We 
hope that our findings will spur further research into conges- 
tion control dynamics to obtain a fundamental understand- 
ing of a future Internet with multiple coexisting congestion 
control algorithms and protocols. 
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